@steveklabnik @guilleiguaran can you take a look?

I am afraid this will cause unintended side effects. If you have a mountable engine, the script_name will also be set but in this case, asset_path still should not consider script path because the entity responsible for delivering assets is in the main application (sprockets in this case).

So I think we should create a mountable engine and ensure we can still access its assets after this patch. Things can get even trickier, because you have can have a mountable engine with Passenger's script_name and in this case we should use only the one coming from passenger. Here are a couple places to look at:

• config.relative_url_root - if this option still exist in action controller, it will give you only the passenger stuff therefore you can rely on it instead
• If not, the code in this module is a good starting point: https://github.com/rails/rails/blob/master/actionpack/lib/action_controller/metal/url_for.rb

As far as I can tell AC still has a relative_url_root option but I think this won't fix the problem. If I interpret this test correctly: https://github.com/rails/rails/blob/master/actionpack/test/template/asset_tag_helper_test.rb#L558-L573
That option is already considered when computing the asset path and it won't be set when you change the rack mount point.

@senny you're meant to set config.relative_url_root to the same as the mount point for the application. IIRC, the original intention for Rails 3.0 was to deprecate it and the environment variable RAILS_RELATIVE_URL_ROOT and use SCRIPT_NAME exclusively. However it was undeprecated because of the need to be able get the relative url root outside of a request context like precompiling assets.

I think we need to have a CF chat about the various options and come up with a plan for sorting this out.

@pixeltrix thanks for clarifying. I put my work on hold and catch you on CF.

I'm closing this one as this is not a viable solution. I'm working on a different approach.